Overview
It is desirable to write applications in such a way that they can be ported to new hardware without unnecessary re-work. If all of the code contained within methods and threads is 100% portable then it can be re-compiled to run on a wide range of operating systems and platforms. However, it is inevitable that some operating system specific or device specific code will be required for many applications and this should not be allowed to compromise the portability of the application.
Isolating Non-Portable Code in a Device Object
In order to maintain application portability it is good practice to put non-portable application code into a Device object:
By separating this code from the main application and therefore clearly identifying it as non-portable, the process of porting the application becomes much simpler. In addition to re-compiling the application for the target platform, the devices must be re-implemented for that platform. By definition, the rest of the application will not require any code changes.
Common APIs and Switching Devices
In addition to providing portability across platforms, devices provide another benefit. By providing a consistent API for a class of device (e.g. streaming devices), the device can be quickly exchanged to provide support for an alternative underlying device. For example, a TCP/IP device could be switched for an ATM device or even a shared memory device for test purposes.
How Devices are Used by Methods and Threads
Devices do not execute under their own power, like methods and threads do. Instead they are executed by methods and threads as required. Devices are owned by a circuit definition and in order to access them a method or thread must retrieve the definition object using the Parent() function, from where it can access the device object and then call its functions. For more information see Accessing Parent Objects.